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Internet Group Management Protocol (IGMP) / 
Multicast Listener Discovery (MLD)-Based Multicast Forwarding 
("IGMP/MLD Proxying") 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 
Abstract 


In certain topologies, it is not necessary to run a multicast routing 
protocol. It is sufficient for a device to learn and proxy group 
membership information and simply forward multicast packets based 
upon that information. This document describes a mechanism for 
forwarding based solely upon Internet Group Management Protocol 

(IGMP) or Multicast Listener Discovery (MLD) membership information. 


1. Introduction 


This document applies spanning tree multicast routing [MCAST] to an 
Internet Group Management Protocol (IGMP) or Multicast Listener 
Discovery (MLD)-only environment. The topology is limited to a tree, 
since we specify no protocol to build a spanning tree over a more 
complex topology. The root of the tree is assumed to be connected to 
a wider multicast infrastructure. 
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1.1. Motivation 


In a simple tree topology, it is not necessary to run a multicast 
routing protocol. It is sufficient to learn and proxy group 
membership information and simply forward multicast packets based 
upon that information. One typical example of such a tree topology 
can be found on an edge aggregation box such as a Digital Subscriber 
Line Access Multiplexer (DSLAM). In most deployment scenarios, an 
edge box has only one connection to the core network side and has 
many connections to the customer side. 


Using IGMP/MLD-based forwarding to replicate multicast traffic on 
devices such as the edge boxes can greatly simplify the design and 
implementation of those devices. By not supporting more complicated 
multicast routing protocols such as Protocol Independent Multicast 
(PIM) or Distance Vector Multicast Routing Protocol (DVMRP), it 
reduces not only the cost of the devices but also the operational 
overhead. Another advantage is that it makes the proxy devices 
independent of the multicast routing protocol used by the core 
network routers. Hence, proxy devices can be easily deployed in any 
multicast network. 


Robustness in an edge box is usually achieved by using a hot spare 
connection to the core network. When the first connection fails, the 
edge box fails over to the second connection. IGMP/MLD-based 
forwarding can benefit from such a mechanism and use the spare 
connection for its redundant or backup connection to multicast 
routers. When an edge box fails over to the second connection, the 
proxy upstream connection can also be updated to the new connection. 


1.2. Applicability Statement 


The IGMP/MLD-based forwarding only works in a simple tree topology. 
The tree must be manually configured by designating upstream and 
downstream interfaces on each proxy device. In addition, the IP 
addressing scheme applied to the proxying tree topology SHOULD be 
configured to ensure that a proxy device can win the IGMP/MLD Querier 
election to be able to forward multicast traffic. There are no other 
multicast routers except the proxy devices within the tree, and the 
root of the tree is expected to be connected to a wider multicast 
infrastructure. This protocol is limited to a single administrative 
domain. 


In more complicated scenarios where the topology is not a tree, a 
more robust failover mechanism is desired, or more than one 
administrative domain is involved, a multicast routing protocol 
should be used. 
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1.3. Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


This document is a product of the Multicast & Anycast Group 
Membership (MAGMA) working group within the Internet Engineering Task 
Force. Comments are solicited and should be addressed to the working 
group’s mailing list at magma@ietf.org and/or the authors. 


2. Definitions 
2.1. Upstream Interface 


A proxy device’s interface in the direction of the root of the tree. 
Also called the "Host interface". 


2.2. Downstream Interface 


Each of a proxy device’s interfaces that is not in the direction of 
the root of the tree. Also called the "Router interfaces". 


2.3. Group Mode 


In IPv4 environments, for each multicast group, a group is in IGMP 
version 1 (IGMPv1) [RFC1112] mode if an IGMPvl report is heard. A 
group is in IGMP version 2 (IGMPv2) [RFC2236] mode if an IGMPv2 
report is heard but no IGMPvl report is heard. A group is in IGMP 
version 3 (IGMPv3) [RFC3376] mode if an IGMPv3 report is heard but no 
IGMPvl or IGMPv2 report is heard. 


In IPv6 environments, for each multicast group, a group is in MLD 
version 1 (MLDv1l) [RFC2710] mode if an MLDvl report is heard. MLDv1l 
is equivalent to IGMPv2. A group is in MLD version 2 (MLDv2) [MLDv2] 
mode if an MLDv2 report is heard but no MLDvl report is heard. MLDv2 
is equivalent to IGMPv3. 


2.4. Subscription 


When a group is in IGMPvl or IGMPv2/MLDvl mode, the subscription is a 
group membership on an interface. When a group is in IGMPv3/MLDv2 
mode, the subscription is an IGMPv3/MLDv2 state entry, i.e., a 
(multicast address, group timer, filter-mode, source-element list) 
tuple, on an interface. 
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2.5. Membership Database 


The database maintained at each proxy device into which the 
membership information of each of its downstream interfaces is 
merged. The membership database is a set of membership records of 
the form: 


(multicast-address, filter-mode, source-list) 
Please refer to IGMPv3/MLDv2 [RFC3376, MLDv2] specifications for the 
definition of the fields "filter-mode" and "source-list". The 
operational behaviors of the membership database is defined in 
section 4.1. 


3. Abstract Protocol Definition 


A proxy device performing IGMP/MLD-based forwarding has a single 


upstream interface and one or more downstream interfaces. These 
designations are explicitly configured; there is no protocol to 
determine what type each interface is. It performs the router 


portion of the IGMP [RFC1112, RFC2236, RFC3376] or MLD [RFC2710, 
MLDv2] protocol on its downstream interfaces, and the host portion of 
IGMP/MLD on its upstream interface. The proxy device MUST NOT 
perform the router portion of IGMP/MLD on its upstream interface. 


The proxy device maintains a database consisting of the merger of all 
subscriptions on any downstream interface. Refer to Section 4 for 
the details about the construction and maintenance of the membership 
database. 


The proxy device sends IGMP/MLD membership reports on the upstream 
interface when queried and sends unsolicited reports or leaves when 
the database changes. 


When the proxy device receives a packet destined for a multicast 
group (channel in Source-Specific Multicast (SSM)), it uses a list 
consisting of the upstream interface and any downstream interface 
that has a subscription pertaining to this packet and on which it is 
the IGMP/MLD Querier. This list may be built dynamically or cached. 
It removes the interface on which this packet arrived from the list 
and forwards the packet to the remaining interfaces (this may include 
the upstream interface). 


Note that the rule that a proxy device must be the querier in order 
to forward packets restricts the IP addressing scheme used; in 
particular, the IGMP/MLD-based forwarding devices must be given the 
lowest IP addresses of any potential IGMP/MLD Querier on the link, in 
order to win the IGMP/MLD Querier election. IGMP/MLD Querier 
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election rule defines that the Querier that has the lowest IP address 
wins the election. (The IGMP/MLD Querier election rule is defined in 
IGMP/MLD specifications as part of the IGMP/MLD behavior.) So in an 

IGMP/MLD-based forwarding-only environment, if non-proxy device wins 

the IGMP/MLD Querier election, no packets will flow. 


For example, the figure below shows an IGMP/MLD-based forwarding-only 


environment: 
BAN Ea a a 
Upstream | | Upstream 
A(non-proxy) B(proxy) 
Downstream | (lowest IP) | Downstream 
TANZ Seerne a 


Device A has the lowest IP address on LAN 2, but it is not a proxy 
device. According to IGMP/MLD Querier election rule, A will win the 
election on LAN 2 since it has the lowest IP address. Device B will 
not forward traffic to LAN 2 since it is not the querier on LAN 2. 


The election of a single forwarding proxy is necessary to avoid local 
loops and redundant traffic for links that are considered downstream 
links by multiple IGMP/MLD-based forwarders. This rule "piggy-backs" 
forwarder election on IGMP/MLD Querier election. The use of the 
IGMP/MLD Querier election process to choose the forwarding proxy 
delivers similar functionality on the local link as the PIM Assert 
mechanism. On a link with only one IGMP/MLD-based forwarding device, 
this rule MAY be disabled (i.e., the device MAY be configured to 
forward packets to an interface on which it is not the querier). 
However, the default configuration MUST include the querier rule, for 
example, for redundancy purposes, as shown in the figure below: 


BAN Eg. San a Se SoS eee 
Upstream | | Upstream 
A B 
Downstream | | Downstream 
LAN 27 Saat ensten 
LAN 2 can have two proxy devices, A and B. In such a configuration, 
one proxy device must be elected to forward the packets. This 


document requires that the forwarder must be the IGMP/MLD querier. 
So proxy device A will forward packets to LAN 2 only if A is the 
querier. In the above figure, if A is the only proxy device, A can 
be configured to forward packets even though B is the querier. 
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Note that this does not protect against an "upstream loop". For 
example, see the figure below: 


Upstream | | Downstream 
A B 
Downstream | | Upstream 
LANI 2 (SSoacaTSaSSesS oS Ssss Sas e so SSS 


B will unconditionally forward packets from LAN 1 to LAN 2, and A 
will unconditionally forward packets from LAN 2 to LAN 1. This will 
cause an upstream loop. A multicast routing protocol that employs a 
tree building algorithm is required to resolve loops like this. 


3.1. Topology Restrictions 


This specification describes a protocol that works only in a simple 
tree topology. The tree must be manually configured by designating 
upstream and downstream interfaces on each proxy device, and the root 
of the tree is expected to be connected to a wider multicast 
infrastructure. 


3.2. Supporting Senders 


In order for senders to send from inside the proxy tree, all traffic 
is forwarded towards the root. The multicast router(s) connected to 
the wider multicast infrastructure should be configured to treat all 
systems inside the proxy tree as though they were directly connected; 
e.g., for Protocol Independent Multicast - Sparse Mode (PIM-SM) 
[PIM-SM], these routers should Register-encapsulate traffic from new 
sources within the proxy tree just as they would directly-connected 
sources. 


This information is likely to be manually configured; IGMP/MLD-based 
multicast forwarding provides no way for the routers upstream of the 
proxy tree to know what networks are connected to the proxy tree. If 
the proxy topology is congruent with some routing topology, this 
information MAY be learned from the routing protocol running on the 
topology; e.g., a router may be configured to treat multicast packets 
from all prefixes learned from routing protocol X via interface Y as 
though they were from a directly connected system. 
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4. Proxy Device Behavior 


This section describes an IGMP/MLD-based multicast forwarding 
device’s actions in more detail. 


4.1. Membership Database 


The proxy device performs the router portion of the IGMP/MLD protocol 
on each downstream interface. For each interface, the version of 
IGMP/MLD used is explicitly configured and defaults to the highest 
version supported by the system. 


The output of this protocol is a set of subscriptions; this set is 
maintained separately on each downstream interface. In addition, the 
subscriptions on each downstream interface are merged into the 
membership database. 


The membership database is a set of membership records of the form: 
(multicast-address, filter-mode, source-list) 


Each record is the result of the merge of all subscriptions for that 
record’s multicast-address on downstream interfaces. If some 
subscriptions are IGMPvl or IGMPv2/MLDv1 subscriptions, these 
subscriptions are converted to IGMPv3/MLDv2 subscriptions. The 
IGMPv3/MLDv2 and the converted subscriptions are first preprocessed 
to remove the timers in the subscriptions and, if the filter mode is 
EXCLUDE, to remove every source whose source timer > 0. Then the 
preprocessed subscriptions are merged using the merging rules for 
multiple memberships on a single interface (specified in Section 3.2 
of the IGMPv3 specification [RFC3376] and in Section 4.2 of the MLDv2 
specification [MLDv2]) to create the membership record. For example, 
there are two downstream interfaces, Il and I2, that have 
subscriptions for multicast address G. Il has an IGMPv2/MLDv1 
subscription that is (G). I2 has an IGMPv3/MLDv2 subscription that 
has membership information (G, INCLUDE, (S1, S2)). The I1’s 
subscription is converted to an IGMPv3/MLDv2 subscription that has 
membership information (G, EXCLUDE, NULL). Then the subscriptions 
are preprocessed and merged, and the final membership record is (G, 
EXCLUDE, NULL). 


The proxy device performs the host portion of the IGMP/MLD protocol 
on the upstream interface. If there is an IGMPvl or IGMPv2/MLDv1 
querier on the upstream network, then the proxy device will perform 
IGMPv1 or IGMPv2/MLDv1 on the upstream interface accordingly. 
Otherwise, it will perform IGMPv3/MLDv2. 
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If the proxy device performs IGMPv3/MLDv2 on the upstream interface, 
then when the composition of the membership database changes, the 
change in the database is reported on the upstream interface as 
though this proxy device were a host performing the action. If the 
proxy device performs IGMPvl or IGMPv2/MLDv1 on the upstream 
interface, then when the membership records are created or deleted, 
the changes are reported on the upstream interface. All other 
changes are ignored. When the proxy device reports using IGMPvl or 
IGMPv2/MLDv1, only the multicast address field in the membership 
record is used. 


4.2. Forwarding Packets 


A proxy device forwards packets received on its upstream interface to 
each downstream interface based upon the downstream interface’s 
subscriptions and whether or not this proxy device is the IGMP/MLD 
Querier on each interface. A proxy device forwards packets received 
on any downstream interface to the upstream interface, and to each 
downstream interface other than the incoming interface based upon the 
downstream interfaces’ subscriptions and whether or not this proxy 
device is the IGMP/MLD Querier on each interface. A proxy device MAY 
use a forwarding cache in order not to make this decision for each 
packet, but MUST update the cache using these rules any time any of 
the information used to build it changes. 


4.3. SSM Considerations 


To support Source-Specific Multicast (SSM), the proxy device should 
be compliant with the specification about using IGMPv3 for SSM [SSM]. 
Note that the proxy device should be compliant with both the IGMP 
Host Requirement and the IGMP Router Requirement for SSM since it 
performs IGMP Host Portion on the upstream interface and IGMP Router 
Portion on each downstream interface. 


An interface can be configured to perform IGMPvl or IGMPv2. In this 
scenario, the SSM semantic will not be maintained for that interface. 
However, a proxy device that supports this document should ignore 
those IGMPvl or IGMPv2 subscriptions sent to SSM addresses. And more 
importantly, the packets with source-specific addresses SHOULD NOT be 
forwarded to interfaces with IGMPv2 or IGMPvl subscriptions for these 
addresses. 


5. Security Considerations 
Since only the Querier forwards packets, the IGMP/MLD Querier 
election process may lead to black holes if a non-forwarder is 


elected Querier. An attacker on a downstream LAN can cause itself to 
be elected Querier, and as a result, no packets would be forwarded. 
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However, there are some operational ways to avoid this problem. It 
is fairly common for an operator to number the routers starting from 
the bottom of the subnet. So an operator SHOULD assign the subnet’s 
lowest IP address(es) to a proxy (proxies) in order for the proxy 
(proxies) to win the querier election. 


IGMP/MLD-based forwarding does not provide the "upstream loop" 
detection mechanism described in Section 3. Hence, to avoid the 
problems caused by an "upstream loop", it MUST be administratively 
assured that such loops don’t exist when deploying IGMP/MLD Proxying. 


The IGMP/MLD information presented by the proxy to its upstream 
routers is the aggregation of all its downstream group membership 
information. Any access control applied on the group membership 
protocol at the upstream router cannot be performed on a single 
subscriber. That is, the access control will apply equally to all 
the interested hosts reachable via the proxy device. 
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